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(54) Verfahren zur rechnergestOtzten Zahlungsabwfddung uber Zahlungssysteme 

(57) Die Erfindung bezeichnet ein Vertahren zur 
rechnergestOtzten ZahlungsabwicWung uber Zahlungs- 
systeme urrter der Zwischenschaltung eines Finanz- 
dienstleisters (3) der dieses Zahlungssystem (4) 
unterstQtzt wobei eine sichere Obertragung von Daten 
uber Datenverbindungen (6a). (6b), (6c) in Netzen (5) 
gewahrleistet wird. Die Aufgabe besteht darin. dem 
Handler (2) mehrere fur den Kunden (1) mogliche Zah- 
lungssysteme (4) zur Verfugung zu steJIen. ohne den 
Handler (2) selbst zur Integration dieser Zahlungssy- 
steme (4) zu zwingen. Dies wird gelost. indem von 
einem Vertragsmodul (8) des Rnanzdienstleisters (3) 
dem Handler (2) ein neutral es Handler-Verfragsproto- 
koll (19) zur Verfugung gestelft wird, uber welches eine 
beidsertige Verpf Schtung zwtschen dem Handler (2) und 
dem Kunden (1) abgeschtossen und diese dem Ver- 
tragsmodul (8) Obermrtteft wird. In den werteren Verfah- 
rensschritten wird die ZahlungsabwicWung des Kunden 
(1) in seinem spe&eilen Zahlungssystem (4) sicherge- 
stellt und dessen Status dem Handler (5) ubermitteit 
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Beschreibung 

[0001] Die Erfindung bezeichnet ein Verfahren zur 
rechnergestutzten ZaWungsabwtcktung uber ZaMungs- 
systeme, betreffend einer beidseitigen Verpftichtung, 5 
insbesondere eines Kaufvertrages, zwischen einem 
Kunden und einem Handler unter der Zwischenschal* 
tung eines F i nan zdienst leisters, insbesondere einer 
Bank, der dieses Zahtungssystem unterstutzt, wobei 
durch spezieJIe Clbertragungssysteme eine sichere w 
Ubertragung von Daten uber Oatenverbindungen in 
Netzen gewahrleistet wird. 

[0002] Clbiicherweise bietet ein Handler den Kunden 
bestimmte Waren an, die der Kunde auswaWt Hat sich 
der Kunde zum Kauf entschtossen, kbmmt es zum is 
AbschluB eines Kaufvertrages zwischen dem Kunden 
und dem Handler. In Folge des Vertrages zahtt der 
Kunde in einem Zahlungsverfahren (bsw. durch Barzah- 
lung) den Kaufpreis und der Handler ubergrbt die ver- 
kaufte Ware. 20 
[0003] Eine modifizierte Van ante dieses Zahlungsver- 
fahrens stellt der Kauf uber Kreditkarten Oder uber ahn- 
liche Zahtungssysteme dar. Dabet wird ein 
Zahlungssystembetreiber, zumeist eine Bank, zwischen 
den Handler und den Kunden geschattet Der Kunde 25 
bezahtt demnach nicht direkt sondem der Zahlungssy- 
stembetreiber burgt (mrttels der Kredrtkarte) fur die Zah- 
lungsfahigkeit des Kunden. Zu einem spat er en 
Zertpunkt bucht der Zahlungssystembetreiber den falli- 
gen Kaufpreis vom Konto des Kunden ab und Qberweist 30 
den Kaufpreis auf das Konto des Handlers. Fur diesen 
Vorgang verlangt er ublicherweise eine Gebuhr. In der 
Praxis si rid unterschiedliche Zahtungssysteme rrrit ver- 
schiedenen Konditionen fur unterschiedliche Einsatz- 
zwecke notwendig. 35 
[0004] Viele mod erne Zahlungssysteme sind als Son- 
derfunkttonen von DVA (Datenverarbeitungsanlagen) 
rechnergestotzt ausfflhrbar (IPC G06F 17/60). Dieser 
technische Hintergrund wird betspieisweise in der 
Druckschrift EP OS 0668 579 A2 im Zusammenhang 40 
mit Keditkarten und in der Druckschrrft WO 95/1 9010 im 
Zusammenhang mit Homebankingsystemen erwahnt 
Oiese unterschiedlichen Zahlungssysteme der einzel- 
nen Zahlungssystembetreiber sind jeweils modrfiziert 
und in der Reg el untereinander nicht Oder nur einge- 4s 
schrankt kompatbel. BezOglteh des inter nationalen 
Zahlungsverkehrs sind nationale Zahlungsmittet men- 
genmaBig verbrerteter als einzelne intemationate Zah- 
lungssysteme. 

[0005] Mod erne Clbertragungssysteme fur Informatio- so 
nen fur Oatenverbindungen im Femverkehr (IPC H04L), 
beispieteweise das Internet ermoglichen die Werbung 
des Handlers uber diese Clbertragungssysteme. Dazu 
bietet der Handler eine Werbeirtformation an, uber wel- 
che er seine Waren prasentiert. Mrttels eines vorgefer- ss 
ttgten Kaufvertrages kann der Kunde bequem den 
Kaufvertrag rechtskraftjg werden tassen, indem er den 
unterschriebenen Kaufvertrag an den Handler sendet 



beispieJsweise per Post, per Fax Oder uber andere 
(rechtDch anerkannte) eleWronrsche Ubertragungssy- 
sterrte 

[0006] Bei der Ubermrttrung von Daten (personfiche 
Informationen aus Kaufvertragen, Einzelheiten der Zah- 
lungsabwcWung) auf modernen Ubertragungssyste- 
men (z.B. im Internet) besteht jedoch die Gefahr der 
unberechtigten Kenntnis, Benutzung oder Modrfizierung 
dieser Daten. Aus cfiesem Grund wurden kryptographi- 
sche Verfahren errtwickelt die auch auf elektronischen 
Wege eine sich ere Ubertragung, das heiBt sicher vor 
Manipulation und Zugriff, von Daten zwischen zwei Teil- 
nehmern ermoglichen (IPC H04L 9/00). Dieser techni- 
sche Hintergrund wird bsw. in der Druckschrift WO 
97/16779 im Zusammenhang mh der Eingabesicherung 
und InformationsQbertragung sowie in der Druckschrift 
EP OS 0668 580 A1 im Zusammenhang mit der 
Authenttsierung der Teilnehmer erwahnt. 
[0007] Derartige kryptographische Verfahren werden 
jeweils in einem spezrfrschen Zahtungsmodul realisiert 
und konnen Hardware basierend und Software basie- 
rend sein. Im ersten Fall benotigt jeder Teilnehmer eine 
(gunstig individuelle) Hardware zur Ver- und Errtschlus- 
selung der Daten. Im zweiten Fall wird dies bei zumin- 
dest einem Teilnehmer durch identische Hardware rrrit 
(gunstig indrviduellen) verschlusselten Parametem 
erziert (andern sich zumeist in der Zertsparoie einer 
moglichen Entschlusselung dieser). Bei Finanzdienst- 
leistern. insbesondere bei Banken, ist eine rechnerge- 
stutzte ZahlungsabwicMung (IPC G06F 19/00) bei 
modernen Obertragungssystemen (z.B. im Internet) nur 
Ansatzweise mit spezrfischen Zahlungssystemen eta- 
Wiert (z.B. SET(secure electronic transition)). 
[0008] Durch die vielfalttgen Mogtichkeiten zum 
AbschluB eines Vertrages zwischen dem Kunden und 
dem Handler, insbesondere auf elektronischem Wege, 
hat der Kunde die Mogltchkeit, zwischen den verschie- 
denen Zahlungsverfahren (Barzahlung per Nach- 
nahme. Clberweisung, Lastschrrft, Kredrtkarte, ...), den 
moglichen Zahlungssystemen (z.B. VISA-Card; EC- 
Kredrtkarte; SET, PIN/TAN (personal identity num- 
ber Aransacti on indetrty number), Geldkarte, ...} und den 
dam it verbundenen Konditionen auszuwahlen. Dies 
setzt jedoch voraus, daB der Handler diese Zahlungs- 
verfahren und Zahtungssysteme anbtetet 
[0009] Im Interesse der Kundenorientierung ist der 
Handler in der Reg el bemOht samtiiche Zahlungsver- 
fahren und Zahlungssysteme anzubieten. Dieses 
Bemuhen bedingt jedoch fOrden Handler notwendig die 
Integration dieser Zahlungssysteme, verbunden mit 
einem groBen organisatotischen Aufwand (z.B. jeweils 
verschiedene Konten), Unkosten (fur die Teilnahme an 
den jeweiligen Zahlungssystemen). einem hohen 
Kostennsiko und der Notwendlgkert. die notwendig en 
Mrttel fQr die entsprechenden Zahlungssysteme (Kredit- 
kartenleser, ZaWungsmodule) stats eirtsatzbereit zur 
VerfOgung zu haften. Aus diesen Grund en sind Zah- 
lungssysteme fur Handler sehr kompliziert integrierbar 
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und neu entwtckefte schwer in groBem MaBstab einzu- 
fohren. 

[0010] Die Aufgabe der Erfindung ist es. ein oben 
beschriebenes Verfahren zur rechnergestutzten Zah- 
lungsabwicktung Qber Zahtungssysteme zu entwickeln, 
welche die aufgefQhrten Nachteile besettigt und dem 
Handler mehrere fur den Kunden mOgliche Zahtungssy- 
steme zur Verfugung stellt ohne den Handler sefbst zur 
Integration dieser Zahlungssysteme zu zwingen. 
[001 1 ] Die Aufgabe wird durch die im Patentanspruch 
1 aufgefQhrten Merkmale gelOst. Bevorzugte Werterbil- 
dungen ergeben sich aus den Unteranspruchen. 
[0012] Das Wesen der Erfindung besteht darin, da S 
Qber eine geschlossene Datenverbindung Qber Netze 
in einem 1 . Schrftt 

der Kunde seine gewunschten Waren und Zahtungssy- 
steme dem Handler Qber die Datenverbindung mrtteitt 
und danacn durch den Handler die Kundeninrtialisie- 
rung des Kunden erfolgt, 
in einen 2. Schritt 

der Handler Qber eine Datenverbindung zu einem Ver- 
tragsmodul bei einem RnanzdienstJeister die Konditio- 
nen fur die gewunschten Zahlungssysteme abfragt und 
dieses sie ihm sicher Qbermittert, 
in einem 3. Schritt 

der Handler Qber die Datenverbindung dem Kunden 
sicher ein Auswahl-Modul ubermittert, welches, jeweits 
etnzeln fur ale gewunschten und verfOgbaren Zahlungs- 
systeme, das Konkrete Angebot des Handlers an den 
Kunden beinhattet 
in einem 4. Schritt 

der Kunde ein einzelnes konkretes Angebot des Hand- 
lers im Auswahl-Modul auswahtt und damit eine beidsei- 
tige VerpfBchtung eingeht, der en InhaH das Auswahl- 
Modul sicher Qber die Datenverbindung dem Handler 
und sicher Qber die Datenverbindung dem Vertragsmo- 
dul Qbermittett, welches sie auf ihre Richtigkeit Qber- 
pruft und unter der eihdeutigen ProzeBnummer 
speichert. 
in einem 5. Schritt 

das Auswahl-Modul die fur das ausgewahlte spezrfische 
Zahlungssystem verfOgbare sichere Datenverbindung 
zwischen einem spezifischen Kunden-Zahlungsmodul 
und dem zugeordneten spezifischen Vertragsmodul- 
Zahtungsmodul aktiviert und den tnhatt der beidseitigen 
Verpf fichtung dem spezifischen Zahlungssystem uber- 
gibt 

in einem 6. Schritt 

der Kunde die notwendigen Erganzungen in dem spezi- 
fischen Zahlungssystem vomimmt und die Zahlungsab- 
wicWung mrt dem Handler Qber das spezrfische 
Kunden-Zahlungsmodul, die Datenverbindung und das 
spezrffsche Vertragsmodul-Zahl ungsmodul sicher 
anweist 

in einem 7. Schritt 

das spezifeche Vertragsn^odul-Zahtungsmodul die 
angewiesene Zahtungsabwickiung an eine spezrfische 
Zahtungssystem-DVA des spezifischen Zahtungssy- 



stembetreibers tatigt 
in einem 8. Schritt 

das Vertragsmodul die spezrftsche Zahlungssystem- 
DVA des spezifischen Zahtungssystembetreibers liest. 

5 dessen Eintrage rrrit dem gespeicherten Inhalt der beid- 
seitigen Verpflichtung vergleicht und Qber die Datenver- 
bindung den Handler sicher Qber den Status der 
Zahtungsabwickiung informiert, 
in einem 9. Schritt 

io die Oberweisung von der spezifischen Zahlungssy- 
stem-DVA auf das Konto des Handlers erfolgt. 
[001 3} Die Vorteile der Erfindung liegen insbesondere 
in Folgendem: 

is • Der Handler muB die einzelnen spezifischen Zah- 
tungssysteme drifter Zahlungssystembetreiber 
rticht selbst integrieren, da dies Qeweils ein maJ) der 
RnanzdienstJeister des Handlers Qbernimmt 
Das Vertragsmodul Qberwacht im Inter esse des 

20 Handlers die ErfOJIung der sich aus dem beidsertkj 
verpffichtenden Vertrag fQr den Kunden ergebende 
Zahlungsverpflichtung, die dieser mrt einem dritten 
Zahlungssystembetreiber abwicketL Der Handler 
erhatt dadurch die notwendige Sicherheit fQr die 

25 Erfullung der Verpflichtung seinerserts. 

• Speziell fQr die Datenverbindung Handler - Finanz- 
dienstieister ist vorteilhaft, daS der Handler eine 
zertifizierte Zahlungsbestatjgung fQr die Erfullung 
der sich aus der beidserbgen VerpfBchtung erge- 

30 bend en Zahlungsanweisung des Kunden erhatt, die 
Signatur prufen kann und alle notwendigen ProzeB- 
daten im Vertragsprotokoll mttgetiefert bekommt. 

• Speziell fQr die Datenverbindung Handler - Kunde 
besteht eine Kanalstcherhert (bsw. Qber einen 

35 SSL), die Handleriderrtrtat und Richtigkeit der 
Bestetldaten ist durch den Kunden prufbar. das Ver- 
tragsprotokoll hat alle notwendigen ProzeBdaten, 
so da 8 bei Datenausfall in den Basissystemen das 
Vertragsprotokoll aus sich selbst regeneriert wer- 

40 den kann. Der Handler arbeitet stets mrt demsefoen 
neutralen Vertragsprotokoll, unabhangig von dem 
spezifischen Zahlungssystembetreiber des Kun- 
den. Dieser wiederum kann seine gewohnten Zah- 
lungsanweisung en Qber seinen spezifischen 

45 Zahlungssystembetreiber abwickeln und nutzt des- 
sen MogJtchkeiten vol) aus. 

• Speziell fQr die Verbindung Kunde - Finanzdienst- 
ieister, da die Kundendaten nicht durch das Ver- 
tragsmodul an den RnanzdienstJeister Cbergeben 

so werden. Die Zahtungsabwickiung erfolgt direkt zwi- 
schen dem Kunden und dem spezifischen Zah- 
lungssystembetreiber (Eigenschaften des 
spezifischen Zahlungssystems gelten) 
AJIe Datenverbi ndung en Qber Netze sind durch die 

55 Verwendung von Krytographie sicher. 

[0014] Die Erfindung wird als AusfQhrungsbei spiel an 
Hand von 
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Fig. 1 als Schema einer ZahfungsabwicWung 
naher erlautert 

[0015] Nach Rg. 1 wild eine ZaWungsabwicWung not- 
werxfig, wertn ein Kunde 1 die Werbung eines Handlers 
2. welcher mit einem Rnanzdienstleister 3 (insbesond- s 
ere mit Banker) in Geschaftsverbindung stent pruft, 
eine beidseitige Verpflichtung (z.B. einen Kaufvertrag) 
einzugehen beabsichtigt und die ihn irtteressierenden 
gewunschten Waren und Zahlungssysteme 4 (z.B. SET, 
EURO-Cash) auswahlt. FOr eine Ubertragung von 10 
Oaten $ind der Rnanzdienstleister 3 mit dem Kunden 1 , 
der Finanzdienstleister 3 mit dem Handler 2 sowie der 
Kunde 1 mit dem Handler 2 uber Netze 5 (z.B. dem 
Internet) bidirektional durch geschlossene Datenverbin- 
dungen [6a, 6b, 6c] verbunden. Weitertiin besteht eine is 
Datenverbindung 7 zwischen dem Rnanzdienstleister 3 
und dem spezrftschen Zahlungssystem 4 sowie inner- 
halb derer Strukturen (bsw. zu den zugeordneten Kon- 
ten). Der Rnanzdienstleister 3 ist rrtit dem Kunden 1, 
abhangig vom spezifischen Zahlungssystem 4, uber die 20 
Datenverbindungen 6a sicher verbunden, ebenso der 
Rnanzdienstleister 3 mit dem Handler 2 und dieser mit 
dem Kunden 1 uber die Datenverbindung 6b und 6a. 
Dies kann Hardware basierend Oder Software basie- 
rend durch geeignete Clbertragungssysteme (bsw. uber 25 
Verschlusselung mit einem 128brt SSL) erfolgen. Der 
Zahlungsvorgang zwischen dem Kunden 1 und dem 
Handler 2 erfolgt vollstandig innerhalb des spezifischen 
Zahlungssystems 4. Die Clberwachung und Steuerung 
des Zahlungsvorgangs uber spezifische Zahlungssy- 30 
steme 4 erfolgt uber das Vertragsmodul 8, welcher uber 
die RnanzdiensUeister-EDV 9 auf das Konto des Hand- 
lers 2 zugreifen kann. Dazu stent der Vertragsmodul 8 
des Finanzdienstletsters 3 des Handlers 2 uber je einen 
Zahlungssystemadapter 10 mit den jewetligen spezifi- 35 
schen Vertragsniodul-Zahlungsrnodulen 11 des zuge- 
hongen Zahlungssystems 4 im Datenaustausch. 
Innerhalb des Zahlungssystems 4 besteht intern ein 
Datenaustausch zwischen dem Kunden 1 und dem 
Rnanzdienstleister 3 des Handlers 2 uber ein Kunden- 40 
Zahlungsmodul 12 und dem Vertragsmodul-ZaMungs- 
modul 11. AuBerhalb des Zahlungssystems 4 besteht 
ein Datenaustausch zwischen dem Vertragsmodul 8 
uber ein Handler -Modul 13 und ein Auswahl-Modu! 14 
mit dem Kunden 1 . Die einzelnen Funktionen zum Ver- 45 
fan r en der ZahlungsaJbwicWung warden vorteilhaft uber 
ein separates Prozeeverwaltungsmodul 15, ein Risiko- 
managementmodul 16 und ein Handlerverwaitungsmo- 
dul 17 innerhalb des Vertragsmodufs 8 ausgefuhrt Die 
Anpassung der einzelnen Protokolle zum Datenaus- so 
tausch der Finanzdienstleister-EDV 9 mit denen ande- 
rer erfolgt vorteilhaft uber einen optional en 
Protokollwandlermodul 18. Dieses Verfahren der Zah- 
lungsabwiddung unterstutzt bei dem Handler 2 im Ver* 
tragsprotokdl vorteilhaft ein neutrales Handler- 55 
Vertragsprotokoll 19 und bei dem Kunden 1 zur Zah- 
lungsabwicktung eine dem speziftschen Zahlungssy- 
stem 4 spezifische Zahlungsanwetsung (20). Innerhalb 



des spezif ischen Zahlungssystems 4 wird die Zahlungs- 
abwicktung uber eine spezifische Zahlungssystem- EDV 
21 (bsw. mit einem Zwischen konto. welches als Sam- 
melkonto dient) vorgenommen. Die spezifische Zah- 
lungssystem- EDV 21 nimmt die ZahJungsanweisung 
des Kunden 1 bezQgltch des Handlers 2 entsprechend 
den speziftschen Bedingungen im speziftschen Zah- 
lungssystem 4 vor. 

Die ZahlungsabwtcMung erfolgt in nachfofgenden 
Schritten: 

1. Schritt: 

[0016] Durch Auswahl in einem Shoppingsystem des 
Handlers 2 erfolgt zuerst das Full en eines Waren korbes 
durch Kunden 1. Nach der Produktauswahl gibt der 
Kunde 1 dem Handler 2 an, mit welch em Zahlungssy- 
stem 4 er zahlen kann Oder mochte. Er macht eine 
Preisanfrage bezuglich der verfOgbaren ZaWungssy- 
steme 4. Danach erfolgt durch den Handler 2 die Kun- 
deninrtialisierung des Kunden 1, falls dieser noch nicht 
initial tsiert ist Es ist vofstellbar, das dies dadurch 
geschieht indem der Kunde 1 das Auswahl -Modul 14 
als Plug- In oder Applet auf seinen PC lacft und anschlie- 
ftend die Zahlungssysteme 4 konftguriert die er urrter- 
stutzen. Dabei gibt er diese vietletcht schon auf dem PC 
vorhandenen speziftschen Kunden-Zahlungsmodule 12 
an 

2. Schritt: 

[0017] Der Handler 2 tfitigt eine Bewertungsanfrage 
fOr die Zahlungssysteme 4, indem er uber die Datenver- 
bindung 6b zu einem Vertragsmodul 8 bei einem 
Rnanzdienstleister 3 die Konditionen fur die gewunsch- 
ten Zahlungssysteme 4 abfragt und dieses sie ihm 
sicher ubermittelL Dabei arbeitet der Handler 2 stets mit 
demseiben neutralen Handler-Vertragsprotokoll 19. Die 
sichere Verbindung wird zwischen dem Vertragsmodul 
8 und dem Handler -Modul 13 aufgebaut Das Vertrags- 
modul 8 uberpruft die Produkt- und Zahlungsanforde- 
rungsinformationen auf ihre Richtigkett (und optional 
der Validitat des Handlers 2). 

3. Schritt: 

[0018] Der Handler 2 Qbermrttett Qber die Datenver- 
bindung 6c dem Kunden 1 sicher ein Auswahl-Modul 
14, welches, jeweils einzeln fQr die gewunschten und 
verfugbaren Zahlungssysteme 4, das konkrete Angebot 
des Handlers 2 (Kaufabsichts- und Zahlungsartein- 
schrankungen) an den Kunden 1 beinhaltet. 

4. Schritt 

[0019] Der Kunde 1 wahlt ein einz eines konkretes 
Angebot des Handlers 2 im Auswahl -Modul 14 aus (der 
Kunde 1 bestatigt den Kauf und das Zahlungssystem 4) 
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und geht damit eine beidseitige Verpf nchtung ein, deren 
Inhalt das Auswahl-Modul 14 sicher Qber die Datenver- 
bindung 6c dem Handler 2 und sicher uber die Daten- 
verbindung 6b dem Vertragsmodul 8 ubermrttett, 
welches sie (die Produkt- und Zahlungsarrforderungsin- 5 
fa mationen) auf ihre Richtigkeit (und optional der Vali- 
drtat des Handlers 2) QberprOft und bis zur Bestatigung 
der Zahlung urtter der eindeutigen ProzeBnummer spei- 
chert AnschtieBend werden die Zahiungs- ProzeB- und 
Produktinformationen an das Clearingsystem des w 
Finanzdienstleisters 3 ubertragen. Es ist vorstellbar. 
daB ebenfalls eine Ubertragung der Produktliste mit 
entsprechenden ProzeBinformationen an den Kunden 1 
erfolgt. 

15 

5. Schritt: 

[0020] Es erfolgt die standardisterte Zahlungsabwick- 
lung durch den Kunden 1. Er aktiviert Qber das Aus- 
wahl-Modul 14 die fur das ausgewahlte spezrfische 20 
Zahlungssystem 4 verfOgbare (ein spezrfisches Kun- 
den-Zahlungsrnodul 12 des Finanzdienstleisters 3 oder 
das eines drift en Zahlungssystembetreibers) sichere 
Datenverbindung 6a zwischen einem Kunden-Zah- 
lungsmodul 12 und dem zugeordneten spezifischen 25 
Vertragsmodul-Zahlungsmodul 11 und ubergfot den 
InhaH der beidseitigen Verpflichtung dem spezifischen 
Zahlungssystem 4. Optional erfotgt eine Vorinrtialisie- 
rung des Kunden-Zahlungsmodul 12 mit Betrag, Wah- 
rung und welter en Daten Es ist vorstellbar, daB das 30 
Kunden-Zahlungsmodul 12 des Finanzdienstleisters 3 
selbst stets verfugbar ist, indem es als Plug- In oder 
Applet auf den PC des Kunden 1 ubertragen wird. 

6. Schritt: 35 

[0021] Der Kunde 1 ntmmt die notwendigen Ergan- 
zungen in dem spezrftschen Zahlungssystem 4 vor und 
weist die ZahtungsabwicWung mit dem Handler 2 Qber 
das spezifische Kunden-Zahlungsmodul 12, die Daten- 40 
verbindung 6a und das spezifische Vertragsmodul-Zah- 
tungsmodul 11 sicher an. Dabei arbeitet der Kunde 1 
mit den gewohnten spezifischen Zahiungsanweisungen 
20 seines gewahtten Zahlungssystemanbieters. Es ist 
vorsteltbar, daB der Finanzdienstleister 3 fur den Kun- 45 
den 1 uberhaupt nicht erkenrtbar in Erscheinung tritt 

7. Schritt: 

[0022] Das spezifische Vertragsnxxiul-Zahfungsmo- so 
dul 1 1 tatigt die angewiesene Zahlungsabwicklung uber 
die spezifische Zahlungssystem- E DV 21 an ein Zwi- 
schenkonto des spezifischen Zahlungssystembetrei- 
bers. Die Zahlungsantwort des spezifischen 
Zahlungssystems 4 wird vom Vertragsmodul 8 regi- 55 
striert Bet erfotgreichem Zahlungseingang wird der 
Betrag spater dem (Clearing) Sarnmelkonto des 
Rnanzdienstletsters 3 gutgeschrieben und in das Kon- 



ten- oder Verwartungssystem eingetragen. 

8. Schritt: 

[0023] Das Vertragsmodul 8 liest uber die spezifische 
Zahlungssystem- EDV 21 das Zwischenkonto des spezi- 
fischen Zahlungssystembetreibers, vergfeicht dessen 
Eintrage mit dem gespeicherten tnhait der beidsertigen 
Verpflichtung und irtformiert sicher Qber die Datenver- 
bindung 6b den Handler 2 uber den Status der Zah- 
lungsabwicklung (Zahlungsbestatigung). Dadurch hat 
das Vertragsmodul 8 die Erfullung der sich aus dem 
beidseitig verpf tichtend en Vertag ergebende Zahlungs- 
verpftichtung uberwacrrt, wobet die Zahlungsabwick- 
lung direkt uber spezifische Zahlung ssysteme 4 
erfolgte. Der Handler 2 hat die Gewahr (fur deren Erful- 
lung der Finanzdienstleister 3 bOrgen kann), daB die 
Zahlungsverpflichtung des Kunden 1 erfullt wurde und 
kann senerseits die Ware an den Kunden 1 ubereig- 
nen. 

9. Schritt: 

[0024] Die Oberweisung vom Zwischenkonto auf das 
Konto des Handlers 2 erfolgt Es ist vorstellbar, daB in 
vereinbarten zeitJichen Abstanden eine Abarbeitung der 
getatjgten Transaktionen erfolgt, bsw. ein Abgfeich der 
Eingange auf das Sarnmelkonto mit deren Abbuchun- 
gen, eine Fehler- und Sonderfallbehandlung bei Protte- 
men. eine Provisionsabrechnung for den Handler 2. ein 
monatjiches Versenden der Abrechnung (auch elektro- 
nisch oder auf Papier in unterschiedlichen Detailie- 
rungsgraden mogltch) usw. 

Vorteilhaft ist im 10. Schritt: 

[0025] Der Handler 2 erstattet dem Finanzdienstlei- 
ster 3 eine Gebuhr entsprechend eines Vertrages zwi- 
schen dem Handler 2 und dem Finanzdienstleister 3. 
So ist es denkbar, daB bei der Oberweisung der Betrage 
an den Handler 2 eine Provision des Finanzdienstlei- 
sters 3 einbehaften wird, bsw. indem uber das Protokoll- 
wandlermodul 18 die Oberweisung en vom 
Sarnmelkonto an die Handlerkonten (bsw. Girokonto), 
abzOglich der Margen des Clearingbetreibers, inrtiiert 
werden. So ist es vorteilhaft vorstellbar, daB die einzel- 
nen Kunden 1 abhangig von Zahlungssystem 4 und 
Risikogruppe mrt den real en Kosten der Geidbeschaf- 
fung bewertet werden (ind. Rabat durch Volumen und 
Margen). Diese kOnnen in Sammelkonten zusammen- 
gefaBt, mrt den Systeinbetreiberkosten (ca. 0,1%) 
beaufschlagt sowie mit werterberechneten Kosten und 
auf die einzetnen Handlerkonten aufgeteilt werden. 
[0026] BezOglich der Gewahrletstung einer sicheren 
Datenverbindung 6a, 6b, 6c ist es vorstelbar, daB vor- 
bekannte kryptographische Systems in der nachtokj en- 
den Art verwendet werden: 

Der Handler 2 sendet ein teilweise verschlusseftes 
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Datenpaket (bsw. bestehend aus: verschlGssette Ware, 
unverschtussefte Ware, Zahtungstyp. eindeutige Pro- 
zeBnummer, Hashwert der verscWQsseiten Ware, Regi- 
sternummer des Handlers 2 und dessen Signatur, 
Public Key des Handlers 2) an den Kunden 1 (ohne s 
Kundendaten und Warendaten). AnschlieBend pruft der 
Kunde 1 die Transaklionsdaten auf Identitat (bsw. pruf- 
bar rrtit einem zertHizierten Public Key) und fuhrt eine 
Uberprufung des verschlusselten Wareninhaits (bsw. 
durch Hash-Erzeugung Qber dem lesbaren Wareninhalt w 
und Verglejch mil dem mitgelieferten Hash des ver- 
schlusselten Wareninhaits). AnschlieBend sendet der 
Kunde 1 das Datenpaket an das ProzeBverwaltungsmo- 
dul 15 des Finanzdienstleisters 3 (gegebenenfalls mrt 
Angaben zum Zahlungstyp erganzt). Der Firtanzdienst- js 
leister 3 selbst erhart nur eine ProzeBnummer. Die 
Transakticn wird vom Vertragsmodul 8 angenommen 
und das eigentliche spezifische Vertragsmodul-Zah- 
lungsmodul 11 aufgerufen, wobei die ProzeBnummer 
wertergeleitet wird. Das spezifische Vertragsmodul- 20 
Zahtungsmodul 1 1 baut spezifisch eine sichere Verbin- 
dung 6a zum spezifischen Kunden-Zahlungsmodul 12 
auf. AnschlieBend erfolgt die AbwicMung der Zahtung 
(zwtschen dem spezifischen Zahlungssystembetretber 
3 und dem Kunden 1 ). 25 
Das ProzeBverwartungsmodul 15 erhatt als Ergebnis 
nur, da 8 die Zahlung rrtit der entsprechenden ProzeB- 
nummer abgewickeJt wurde Oder nicht. im letzen Fall 
erfolgt eine entsprechende Fehlermeldung. Die Eigen- 
schaften des entsprechenden Zahlungsmrttels des spe- 30 
ziftschen Zahlungssystems 4 (z.B. Anonymttat) bleiben 
uneingeschrankt erhatten. Nach erfolgt er Zahlung sen- 
det das ProzeBverwartungsmodul 15 die ProzeBnum- 
mer und die Bestatigung der eingegangenen Zahlung 
an den Handler 2. 35 

Verwendete Bezugszeichen 



19 Handler- Vertragsprotokofl 

20 spezifische Zahtungsanweisung 

21 spezifische Zahlungssystem-DVA 

Patentansprflche * 

1. Verfahren zur rechnergestutzten Zahlungsabwick- 
lung uber Zahlungssysteme. bei welchem ein 
Kunde (1) uber eine Datenverbindung (6c) die Wer- 
bung eines Handlers (2) pruft. eine beidseitige Ver- 
pflichtung einzugehen beabsichtigt und die ihn 
interessierenden gewQnschten Waren und Zah- 
lungssysteme (4) auswahrt dadurch gekenn- 
zeichnet, daB 
in einem 1 . Schritt 

der Kunde (1) seine gewQnschten Waren und Zah- 
lungssysteme (4) dem Handler (2) uber die Daten- 
verbindung (6c) mrtteitt und danach durch den 
Handler (2) die KundeninitiaJisierung des Kunden 
(1) erfolgt, 
in einen 2. Schritt 

der Handler (2) Qber eine Datenverbindung (6b) zu 
einem Vertragsmodul (8) bei einem Finanzdienst- 
letster (3) die Kondrtionen fur die gewQnschten Zah- 
lungssysteme (4) abfragt und dieses sie ihm sicher 
Qberrnittett. 
in einem 3. Schritt 

der Handler (2) uber die Datenverbindung (6c) dem 

Kunden (1) sicher ein AuswaW-Modul (14) uberrrtrt- 

tett. welches, jeweils einzeln fur die gewQnschten 

und verfugbaren Zahlungssysteme 4, das konkrete 

Angebot des Handlers (2) an den Kunden (1) 

beinhaitet 

in einem 4. Schritt 

der Kunde (1) ein einzelnes tonkretes Angebot des 
Handlers (2) im Auswahl-Modul (14) auswahrt und 
damit eine beidseitige VerpfBchtung eingeht, deren 
Inhalt das Auswahl-Modul (14) sicher uber die 
Datenverbindung (6c) dem Handler (2) und sicher 
Qber die Datenverbindung (6b) dem Vertragsmodul 
(8) ubermittelt welches sie auf ihre Richtigkeit 
uberpruft und unter der eindeutigen ProzeBnum- 
mer speichert 
in einem 5. Schritt 

das Auswahl-Modul (14) die fur das ausgewahrte 
spezifische Zahlungssystem (4) verfOgbare sichere 
Datenverbindung (6a) zwischen einem spezifi- 
schen Kunden-Zahlungsmodul (12) und dem zuge- 
ordneten spezif ischen Vertragsmodul - 
Zahlungsmodul (11) aktiviert und den Inhalt der 
beidseittgen Verpffichtung dem spezifischen Zah- 
lungssystem (4) Obergibt 
in einem 6. Schritt 

der Kunde (1) die notwendigen Erganzungen in 
dem spezifischen Zahlungssystem (4) vomimmt 
und die ZahlungsabwtcWung mrt dem Handler (2) 
uber das spezifische Kunden-Zahfungsmodul (12), 
die Datenverbindung (6a) und das spezifische Ver- 
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tragsmodut-Zahfungsmodul (11) sicher anweist. 
in einem 7. Schritt 

das spezifische Vertragsmodul-Zahlungsmodut 
(1 1 ) die angewiesene ZahlungsabwicWung an eine 
spezifische ZaWungssystem-DVA (21) des spezifi- $ 
schen Zahtungssystembetreibers tatigt 
in einem 8. Schrit! 

das Vertragsmodul (8) die spezifische Zahlungssy- 
stem- OVA (21) des spezifischen Zahlungssystem- 
betreibers liest, dessen E intra ge mil dem w 
gespeicherten Inhatt der beidseitigen Verpflichtung 
vergleichl und Qber die Oatenverbindung (6b) den 
Handler (2) sicher Qber den Status der Zahlungsab- 
wicMung informiert 

in einem 9. Schritt 1S 
die Uberweisung von der spezifischen Zahlungssy- 
stem-DVA (21) auf das Konto des Handlers (2) 
erfolgt 

2. Verfahren zur rechnergestutzten Zahlungsabwick- so 
lung Qber Zahlungssysteme nach Anspruch 1, 
dadurch gekennzeichnet 

daB der Handler (2) dem Finanzdienstleister (3) 
• eine Gebuhr entsprechend eines Vertrages zwi- 
schen dem Handler (2) und dsm Finanzdienstlei- ss 
ster (3) erstattet. 

3. Verfahren zur rechnergestutzten Zahfungsabwick- 
lung Qber Zahlungssysteme nach einem der 
Anspruche 1 oder 2, dadurch gekennzeichnet, so 
daB zur Gewahrtetstung einer sicher en Datenver- 
bindung (6a). (6b), (6c) kryptographische Systeme 
verwendet werden, indem 

im (3) Schritt 

der Handler (2) ein teifwerse verschlQsseftes Oaten- 35 
paket an den Kunden (1) sendet 
im (4) Schritt 

der Kunde (1) die Transaktionsdaten auf Identitat 
pruft und eine Uberprufung des verschlusseften 
Warenirthatts durchfuhrt, nach dem Eingehen der *o 
beidseitigen VerpfSchtung der Kunde (1) das 
Datenpaket Qber den Handler (2) an das ProzeB- 
verwaJtungsmodul (1 5) des Finanzdienstleisters (3) 
sendet, der Finanzcfienstleister (3) setbst nur eine 
ProzeSnurrtmer erhatt. die Transaktion vom Ver- <5 
tragsmodul (8) anc^nornmen und das eigerrrJiche 
spezifische Verlragsnxxlul-Zahlungsmodul (11) 
aufgerufen wird. w«bei die ProzeBnummer weiter- 
gelertetwird, 

im 6. Schritt so 
die Abwicklung der Zahlung zwischen der spezifi- 
schen Zahfcingssystembetreiber und Kunden (1) 
entsprechend der Datensicherhett des spezif ischen 
Zahlungssystems (4) erfolgt das ProzeBverwal- 
tungsmodul (15) nur ate Ergebnis erhalt. daB die 55 
Zahlung mrt der entsprechend en ProzeBnummer 
abgewickeft wurde oder nicht, wobei im letzen Fall 
eine entsprechend en FehlermeJdung erfolgt. nach 



erfolgt er Zahtung das ProzeBverwaJtungsmodul 
(15) die ProzeBnummer und die Bestatigung der 
eingegangenen Zahfung an den Handler (2) sen- 
det. 
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